[mono][interp] Add max limit to the imported IL when inlining #121580
+11
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
BrzVlad
requested review from
kotlarmilos,
steveisok and
vitek-karas
as code owners
Contributor
|
Tagging subscribers to this area: @BrzVlad, @kotlarmilos |
Copilot finished reviewing on behalf of
BrzVlad
November 13, 2025 13:18
Contributor
There was a problem hiding this comment.
Pull Request Overview
This PR adds a maximum limit on the total amount of IL code imported during method compilation in the Mono interpreter to prevent excessive inlining. Without this limit, methods with many inlineable callsites could result in extremely bloated code, causing significant memory usage and slow compilation times.
Key Changes:
- Introduces a 1MB budget (1,000,000 bytes) for total imported IL code during compilation
- Tracks accumulated IL size across all inlining operations
- Prevents further inlining once the budget is exceeded
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
src/mono/mono/mini/interp/transform.h |
Adds total_il_size field to TransformData struct to track cumulative imported IL |
src/mono/mono/mini/interp/transform.c |
Implements budget constant (1MB), budget check in inlining heuristic, IL size tracking in code generation, and proper save/restore of counter during inlining attempts |
vitek-karas
reviewed
Nov 13, 2025
This was referenced Nov 13, 2025
Open
kotlarmilos
approved these changes
Nov 14, 2025
While we have some simple heuristics on whether we should inline a method or not, we have no limit on how many methods we can inline. So, if a method has 1000 callsites to methods that are inlineable, we will inline each one of them, significantly bloating the code. This is made worse by more advanced SSA optimizations, because the compilation time becomes very slow and uses a lot of memory. The limit is set as a simple upper limit on the total amount of IL code being imported as part of method compilation. This is set to a generous initial value of 1MB, since local testing showed that it is still handled decently well. The largest value obtained from running System.Runtime libtests suite is 100K. A customer provided sample was hitting 8MB of imported code, which was causing GBs of mem usage and several seconds to compile the method. In the end, all this code was discarded anyway, since it was exceeding interpreter offset limits, and we had to retry compilation with inlining disabled.
BrzVlad
force-pushed
the
fix-interp-inline-budget
branch
from
f9a616f to
f30dccd
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While we have some simple heuristics on whether we should inline a method or not, we have no limit on how many methods we can inline. So, if a method has 1000 callsites to methods that are inlineable, we will inline each one of them, significantly bloating the code. This is made worse by more advanced SSA optimizations, because the compilation time becomes very slow and uses a lot of memory.
The limit is set as a simple upper limit on the total amount of IL code being imported as part of method compilation. This is set to a generous initial value of 1MB, since local testing showed that it is still handled decently well. The largest value obtained from running System.Runtime libtests suite is 100K. A customer provided sample was hitting 8MB of imported code, which was causing GBs of mem usage and several seconds to compile the method. In the end, all this code was discarded anyway, since it was exceeding interpreter offset limits, and we had to retry compilation with inlining disabled.